COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	beeson.not[s85,jmc]	Comments on Beeson's paper on knowledge
C00008 ENDMK
C⊗;
beeson.not[s85,jmc]	Comments on Beeson's paper on knowledge

	The paper is written clearly enough, but the formalism
is incompletely developed and seems vague.  Nevertheless, the
following comments can be made.

1. The proposed formalism is too procedural to represent human
common sense knowledge.  The procedures cannot use additional
facts that may become available and relevant if they aren't
built in.  In the restaurant example, suppose Luigi comes to
the door and says that the restaurant opens in five minutes.

2. As long as all the exceptions have to be built into the
rule in advance, there is no significant difference from
putting the negations into the positive part.  I'm not sure
of the role of always having and ELSE part.

The comments about Prolog seem confused to me.  Prolog only allows
the representation of certain information and only allows certain
uses of that information it can represent.

"If logic is to be useful for knowledge representation, a control
structure must be specified."  I don't agree.  Quite different programs
can use the same facts, and we can have facts that we don't as yet
have any way of using.

I don't think default reasoning is correctly characterized in lines
135 and 136.  The point is that many of the C1, C2 etc. aren't even known
when rule is stated and even when the default reasoning is used.
The result of applying circumscription or Reiter default ruless depends
on what facts are taken into account at the time the reasoning is done.
There need be no deliberate decision to ignore known facts; it's just
that the axioms allow for the possibility that more contra-indications
will be discovered later.

lines 143 et seq. raise a point that hasn't been treated in the literature
yet, but I don't agree with the proposed way of looking at it.

The discussion of "something has gone wrong" refers to a different
phenomenon than the one addressed by Reiter and me.

You should look at Winston's treatment of of "if-then-unless" rules.

It seems to me that the "if-then-except" rules are just
ordinary monotonic rules including some case analysis.

The Red Cross rules for poisoning illustrate this point well.
There are no clauses like "do X if you know of no contra-indication";
this would be the essence of a non-monotonic rule.

Actually the unimproved form of the Red Cross rules is closer to
what non-monotonic reason provides for.  Imagine that the patient
is such a fanatical Mormon that he would rather die than drink
the coffee you have available.  The Red Cross didn't think of that
and neither has anyone else till just now.  Genuine non-monotonicity
provides for that but the Beeson rules don't.

The rules for wanting to be in a building also don't provide for
the unexpected.

Prolog programmers do often use "predicates" with side effects in
order to make the program act.  In my opinion they will be sorry,
because it only works when the thinking about action and the
actions themselves behave in a very parallel way, and this often
isn't so.

I confess I didn't understand the Prolog part either, although
I do understand Prolog in general and have written Prolog
programs.

I believe there have been programs which attempt to model their
opponents, and Shannon in the late forties built a machine that
attempted to model its opponent at matching pennies, e.g. it
considered hypotheses like "if tails has come up three times in
a row he will guess heads".  My impression is that no-one had
good enough ideas about modelling the oppponent in chess to
make it seem worthwhile to incorporate them in programs.

Production rules: A key point about actual production rules is that
they contain variables on both sides, and the if-part has to be
matched.

Up to line 647